REMARKS 

This is a full and timely response to the Notice of Non-Compliant Amendment 
mailed December 19, 2007. Applicant has corrected the identifier associated with claim 
14. Reconsideration and allowance of the application and pending claims are 
respectfully requested. 

I. Claim Rejections - 35 U.S.C. § 1 12, Second Paragraph 

Claims 14 and 15 have been rejected under 35 U.S.C. § 112, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which the Applicant regards as the invention. 

In response to the rejection, Applicant has amended claim 14 to recite 
intercepting a "request" instead of a "message". In view of that amendment, it is 
respectfully submitted that the claims define the invention in the manner required by 35 
U.S.C. § 112. Accordingly, Applicant respectfully requests that the rejections to claims 
14 and 15 be withdrawn. 

II. Claim Rejections - 35 U.S.C. § 103(a) 

Claims 1-15 and 25-34 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Kaler, et al. ("Kaler," U.S. Pub. No. 2004/0199586). Applicant 
respectfully traverses. 

As has been acknowledged by the Court of Appeals for the Federal Circuit, the 
U.S. Patent and Trademark Office ("USPTO") has the burden under section 103 to 
establish a prima facie case of obviousness by showing some objective teaching in the 
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prior art or generally available knowledge of one of ordinary skill in the art that would 
lead that individual to the claimed invention. See In re Fine, 837 F.2d 1071, 1074, 5 
USPQ 2d 1596, 1598 (Fed. Cir. 1988). The Manual of Patent Examining Procedure 
(MPEP) section 2143 discusses the requirements of a prima facie case for 
obviousness. That section provides as follows: 

To establish a prima facie case of obviousness, three basic criteria 
must be met. First, there must be some suggestion or motivation, either in 
the references themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach 
or suggest all the claim limitations. 

The teaching or suggestion to make the claimed combination and 
the reasonable expectation of success must both be found in the prior art, 
not in applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 
(Fed. Cir. 1991). 

In the present case, the prior art does not teach or suggest all of the claim 
limitations and there is no suggestion or motivation in the prior art to modify the 
references to include those limitations. 

A. The Kaler Reference 

Kaler discloses a system configured to route electronic messages. As described 
by Kaler, the system comprises a plurality of message processors 205-208 that 
"access" electronic messages. Kaler, paragraph 0059. By way of example, a first 
message processor 205 may by the "initiating" processor that originates the message. 
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second and third message processors 206 and 207 may be "intermediary" processors 
that route the message, and a fourth message processor 208 may be the "receiving" 
processor that is the intended destination for the message. Kaler, paragraph 0065; 
Figure 2. 

Each message processor 205-208 is configured to identify session Information 
when a message is accessed. Kaler provides an explicit definition as to what he means 
by "session information" in paragraph 0041: 

In this description and the following claims, "session information" is 
defined generally to include, but is not limited to, information used to 
represent characteristics of a communication session, such as, for 
example, session identifiers, session names, session priorities, message 
sequences, message sequence names, message sequence priorities, and 
message sequence values. 

Kaler, paragraph 0041. Accordingly, Kaler uses the term "session information" to refer 
to information that facilitates a communication session as opposed to information that 
facilitates evaluation of the components that communicate. See also Kaler, paragraph 
0006. 
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B. Applicant's Claims 
1. Claims 1-12 

Independent claim 1 provides as follows: 

1. A method for collecting data regarding network service 
operation, the method comprising: 

a client sending a request to a network service; 

intercepting the request sent by the client directed to the network 
service; 

storing in a session timing profile information about the request 
including a name of the client, a name of the network service, and a 
request sent time identifying when the request was sent by the client; and 

transmitting the request to the network service. 

As an initial matter, Kaler does not teach or suggest a "method for collecting data 
regarding network service operation" as is explicitly stated in the preamble of 
Applicant's claim 1. In fact, Kaler appears to be unconcerned with the operation of 
network services or the components that host those services. Instead, as described 
above, Kaler is concerned about facilitating communication sessions and the routing of 
messages in association with the communication sessions. Therefore, Kaler's system 
is not even configured to perform the method described by claim 1 . It is for that reason 
that Kaler does not teach or suggest several of the explicit limitations of claim 1. 
Applicant discusses those limitations in the following. 

Turning to the body of claim 1, Applicant notes that Kaler does not teach or 
suggest "intercepting" a request sent by the client and directed to a network service. In 
the final Office Action, it is argued that Kaler teaches such "intercepting" given that the 
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intermediary message processors (e.g., message processors 206 and 207 in Figure 2) 
access a message being sent to another message processor (e.g., message processor 
208 in Figure 2). In reality, the intermediary message processors do not "intercept" any 
messages. Instead, the intermediary message processors merely receive messages 
that are sent to them and forward the messages on to the next message processor. As 
described by Kaler: 

Electronic message 230 can be routed along a routing path from 
end message processor 205 to end message processor 208. Intermediary 
message processors 206 and 207 may be message processors included 
in the routing path. As illustrated by arrow 1 in FIG. 2, end message 

processor 205 can transfer electronic message 230 to intermediary 
message processor 206. Electronic message 230 can subsequently be 
transferred to intermediary message processor 207 as illustrated by arrow 
2 in FIG. 2 and arrive at end message processor 208 as illustrated by 
arrow 5 in FIG. 2. 

Kaler, paragraph 0065 (emphasis added). As is made clear in the above paragraph, 
the intermediary message processor 206 does not intercept the electronic message 
230. Instead, the message processor 205 that created the message intentionally 
transfers the message to the intermediary message processor 206. Such an action, 
i.e., receiving a message that is intentionally transferred to you, cannot reasonably be 
considered to comprise "intercepting" the message. 

Continuing through the body of claim 1 , Kaler further does not teach or suggest 
"storing in a session timing profile information about the request including a name of the 
client, a name of the network service, and a request sent time identifying when the 
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request was sent by the client". In the final Office Action, it is alleged that Kaler 
discloses such storing in paragraphs 0016 and 0041 . This is simply not true. 

As a first matter regarding the "storing in a session timing profile . . ." limitation, 
Kaler's message processors do not store anything in a "session timing profile" because 
Kaler does not even contemplate such a profile. As described above, Kaler is not 
concerned with the operation of the message processors themselves. Therefore, Kaler 
is not concerned with the timing with which those message processors processes 
messages. Accordingly, Kaler's message processors do not have any information to 
store in a "session timing profile" as explicitly required by claim 1 . Although Kaler does 
disclose "caching" session information for use in processing subsequently received 
messages in paragraph 0016, that caching clearly is not storing information for the 
purpose of building a profile as to session timing. Instead, it appears clear that Kaler's 
message processors only temporarily maintain (as suggested by the term "cache") 
information that will be needed to process furthers messages within that same 
communication session. In such a case, the information would be cleared from the 
cache once the communication session is over. 

As a second matter regarding the "storing in a session timing profile . . ." 
limitation, Kaler clearly does not teach or suggest the storing of an^ of "a name of the 
client", "a name of the network service", or "a request sent time identifying when the 
request was sent by the client". Regarding paragraph 0016 of the Kaler reference, 
which was relied upon by the Examiner, Kaler states: 
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The accessing message processor determines if any session 
information should be updated. This can include adding session 
information to (e.g., in response to a query from another message 
processor), removing session information from (e.g., when session 
information is targeted only to the accessing message processor), and/or 
altering session information contained in the electronic message. Session 
information can also be retrieved from the electronic message and cached 
at the accessing message processor (or at some other accessible 
location) to facilitate the appropriate processing of subsequently received 
electronic messages. For example, cached session information can be 
utilized to determine the accessing message processor is associated with 
a communication session and/or message sequence represented in a 
subsequently received electronic message. 

Kaler, paragraph 0016. As is readily apparent from the above paragraph, Kaler is silent 
as to the "name of the client". If the Examiner disagrees. Applicant requests that the 
Examiner explicitly identify the words or phrases in paragraph 0016 that comprise a 
disclosure of such a name. Equally apparent from the above paragraph, Kaler is silent 
as to the "name of the network service". If the Examiner disagrees. Applicant requests 
that the Examiner explicitly identify the words or phrases in paragraph 0016 that 
comprise a disclosure of such a name. 

Turning to the "request sent time" portion of the limitation, the Examiner admits 
that Kaler does not teach or suggest storing a request sent time identifying when the 
request was sent by the client. However, the Examiner argues that the storage of such 
information would have been "obvious and expected" given that, in the Examiner's 
words, Kaler explicitly teaches "session information including time values." Final Office 
Action, page 4. The "time values" upon which the Examiner rests his obviousness case 
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stems from Kaler's solitary identification of a "Delay" value in paragraph 0041. The 
portion of paragraph 0041 to which the Examiner refers provides: 

Session information can be represented using virtually any types of values 
including, numeric values (e.g., 12, D4, 11001, etc.), characters of text 
(e.g., "c", "v", "6", etc.), strings of text (e.g., "06:45:33", "Delay=132 ms", 
etc.), or user-defined values. The definition of session information is 
further defined to include signed and/or encrypted session information (or 
portions thereof), such as, for example, session information that is 
encrypted for a particular recipient. 

Kaler, paragraph 0041 . 

Applicant respectfully submits that Kaler's expression of "Delay=132 ms" does 
not comprise a legitimate suggestion that would motivate a person having ordinary skill 
in the art to store or log session timing information, such as the recited "request sent 
time". Again, Kaler is unconcerned with tracking operation of his message processors. 
Therefore, a person having ordinary skill in the art would not be considering the storage 
of session timing information when reviewing Kaler's disclosure. Moreover, such a 
person would not think to store times at which messages where received, or sent for 
that matter, in view of the cryptic phrase "Delay=132 ms". Not only does that phrase 
provide little more than an indication of a format of session information, the phrase 
raises more questions that answers them. In particular, it is not at all clear from the 
Kaler reference what that phrase means. For all the reader knows, the "delay" 
comprises a time period that a messaging processor should postpone forwarding of a 
received message after it has been processed. Regardless, without more, the 
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"Delay=132 ms" provides little motivation for any modification of the Kaler system to a 
person having ordinary skill in the art. 

In view of the above, it is clear that Kaler does not in fact render claim 1 obvious. 
Applicant therefore respectfully submits that claim 1 and its dependents are allowable 
over the Kaler reference and that the rejections should be withdrawn. 

2. Claims 13-15 

Independent claim 13 provides as follows: 

13. A method for collecting data regarding network service 
operation, the method comprising: 

intercepting a request sent by a client to a network service; 

storing in a session timing profile information about the request 
including a name of the client, a name of the network service, and a 
request received time identifying when the request was received; and 

transmitting the request to the network service. 

Regarding claim 13, Applicant first notes that Kaler does not teach or suggest a 
method for "collecting data regarding network service operation" for reasons described 
above in relation to claim 1. Again, Kaler is concerned about facilitating a 
communication session, not logging information as to the operation of the message 
processors that participate in that communication session. 

Second, Kaler does not teach or suggest "intercepting a request sent by a client 
to a network service" also for reasons described above in relation to claim 1. Again, 
Kaler's message processors merely receive messages that are intentionally sent to 
them. As such, they do not "intercept" the messages. 
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Third, Kaler does not teach or suggest "storing in a session timing profile 
information about the request including a name of the client, a name of the network 
service, and a request received time identifying when the request was received". As 
described above, although Kaler describes "caching" session information for use with 
subsequently received messages of a given communication session, such caching 
clearly is not "storing" information in a "session timing profile". Furthermore, as is also 
described above, Kaler is silent as to storing, or caching for that matter, the "name of 
the client" or the "name of the network service" in paragraph 0016, which was cited by 
the Examiner. 

With further regard to the "storing in a session timing profile . . ." limitation. 
Applicant notes that Kaler does not teach or suggest storing or caching "a request 
received time identifying when the request was received" for similar reasons that Kaler 
does not teach or suggest storing "a request sent time" described in relation to claim 1 . 
As mentioned in the discussion of claim 1, Kaler is unconcerned with tracking operation 
of his message processors, such as the time they receive messages, and the cryptic 
phrase "Delay=132 ms" does not provide a legitimate motivation to a person having 
ordinary skill to store such information. 

In view of the above, it is clear that Kaler does not in fact render claim 13 
obvious. Applicant therefore respectfully submits that claim 13 and its dependents are 
allowable over the Kaler reference and that the rejections should be withdrawn. 
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3. Claims 25-30 

Independent claim 25 provides as follows: 

25. A computer-readable medium that stores a message 
handler, the handler comprising: 

logic configured to intercept messages sent by a client and directed 
to a network service; 

logic configured to store in a session timing profile information 
about the message including a name of the client, a name of the network 
service, and a request sent time identifying when the request was sent by 
the client; and 

logic configured to transmit the message to the network service. 

As an initial matter regarding claim 25, Applicant notes that the claim is explicitly 
directed to a "message handler" and that the Examiner identifies no components within 
the Kaler reference that he believes to constitute such a message handler. Applicant 
therefore respectfully submits that the Examiner has failed to state a prima facie case 
of obviousness against claim 25. Applicant further asserts that Kaler neither teaches or 
suggest such a message handler. 

Turning to the body of claim 25, Applicant submits that Kaler does not teach or 
suggest "logic configured to intercept messages sent by a client and directed to a 
network service" or "logic configured to store in a session timing profile Information 
about the message including a name of the client, a name of the network service, and a 
request sent time identifying when the request was sent by the client" for reasons 
described above in relation to claim 1. Applicant therefore respectfully submits that 
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claim 25 and its dependents are allowable over the Kaler reference and that the 
rejections should be withdrawn. 

4. Claims 31-34 

Independent claim 31 provides as follows: 

31 . A messaging system, comprising: 

a first network service comprising an application program interface 
(API) that is configured to call a message handler; and 

a message handler that is called by the API, the message handler 
being configured to intercept requests sent by the first network service 
and directed to a second network service, to store in a session timing 
profile information about the request including a name of the first network 
service, a name of the second network service, and a request sent time 
identifying when the request was sent by the first network service, to 
interject information into the request including a session identification, to 
transmit the message to the second network service, to receive a 
response from the second network service, and to store in the session 
timing profile information about the response including a name of the 
second network service, a name of the first network service, and a 
response received time identifying when the response was received. 

Kaler does not teach or suggest "a first network service comprising an 
application program interface (API) that is configured to call a message handler". 
Regarding that limitation, Applicant notes that although the Examiner generally alleges 
on page 6 of the final Office Action that Kaler "discloses" an API configured to call a 
message handler, the Examiner provides no citation to the Kaler reference. Applicant 
therefore respectfully submits that the Examiner has failed to make a prima facie case 
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against claim 31. Applicant further notes that Applicant has reviewed the entirety of the 
Kaler reference and can find no disclosure of such an API. 

In addition, Kaler does not teach or suggest a "message handler that is called by 
the API". The Examiner failed to provide a citation of where such a message handler is 
disclosed by Kaler. Therefore, the Examiner has also failed to make a prima facie case 
for that reason. Applicant notes that, if it is the Examiner's position that Kaler's 
message processors comprise a "message handlers", the Examiner cannot further cite 
Kaler's message processors as comprising Applicant's claimed "network services". In 
other words, Kaler's message processors cannot be both "message handler" and 
"network services". Applicant further notes that, given that Kaler does not disclose 
components other than the message processors 205-208, it is clear that Kaler does not 
further disclose a separate message handler, as is required by claim 31 . 

Kaler further does not teach or suggest a message handler or another 
component that Is configured to "intercept requests sent by the first network service and 
directed to a second network service" or "store in a session timing profile information 
about the request including a name of the first network service, a name of the second 
network service, and a request sent time identifying when the request was sent by the 
first network service". Regarding Kaler's message processors, those processors do not 
"intercept" messages and do not store any of "a name of the first network service", "a 
name of the second network service", or "a request sent time" for reasons described 
above in relation to claim 1. 

As a further matter, Kaler does not teach or suggest a message handler or other 
component configured to "store in the session timing profile information about the 



-21- 



response including a name of the second network service, a name of the first networl^ 
service, and a response received time identifying when the response was received" for 
reasons described above in relation to claim 13. 

Applicant therefore respectfully submits that claim 31 and its dependents are 
allowable over the Kaler reference and that the rejections should be withdrawn. 
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CONCLUSION 



Applicant respectfully submits that Applicant's pending claims are in condition for 
allowance. Favorable reconsideration and allowance of the present application and all 
pending claims are hereby courteously requested. If, in the opinion of the Examiner, a 
telephonic conference would expedite the examination of this matter, the Examiner is 
invited to call the undersigned attorney at (770) 933-9500. 



Respectfully submitted, 




-David R. R'isle^^ ' 
Registration No. 39,345 
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